1. Field of the Invention
The present invention is related to a mechanism that enables flexible and dynamic derivation of permissions for system processes using an authenticated description of the executable content run by the process and a site security policy that prescribes the principals that can delegate permissions to content of that description and limits to the permissions that may be delegated.
______________________________________ Glossary ______________________________________ Object Data containing entity. Operation An action that uses an object. Principal A system subject that performs operations on objects (e.g., process) Permissions The set of objects and operations that (or Access Rights) are permitted upon those objects for a specific principal. Current Permissions The permissions of a principal at the current time. Maximal Permissions A principal's permissions that is always a superset of that principal's current permissions. ______________________________________
2. Discussion of the Prior Art
Downloaded executable content are messages that contain programs that are executed upon receipt. It is well-known that downloaded executable content must be executed with limited permissions to prevent content providers from gaining unauthorized access to the downloading principal's resources (e.g., private files).
However, deriving a proper, limited set of permissions that control the execution of content can be difficult. There are two main problems: (1) content can be transient, so their permissions must often be derived anew and (2) no single principal has complete knowledge of what permissions are required and safe for content. Content execution systems enable the creation of custom content that may only be executed once per downloading principal, so the derivation of permissions must not depend upon complete prior knowledge of its behavior. Several principals have limited knowledge about the permissions that a content should be granted, but no one has the breadth of knowledge necessary to derive content permissions. For example, system administrators are often trusted to specify permissions of processes completely (e.g., mandatory access control). However, the control of content requires that system administrators know how a custom application needs to access user data. System administrators cannot know the rights needed by custom content nor can they know the semantics of user files, so they are limited in the access control decisions they can make. Other principals, such as users and application developers, may know these answers, but they are not completely trusted to make access control decisions.
Current systems depend upon predefined mappings between content and principals. Typically, this mapping is based upon the identity of an authenticated signer for the downloaded content. In addition, codebases (i.e., the source locations from which content was downloaded) are also used to identify the rights of content. Derivation of protection domains is limited because only one input is available and this input may be orthogonal to the rights required. The use of the signing principal or codebase to derive rights requires that all content from this principal or codebase be executed with the same rights. Therefore, when new content is created (and its associated public key or codebase) its rights cannot be derived even if the manufacturer and application class are known. A separation between author identity, location, and content description is necessary to overcome this limitation.
Current systems demonstrate that multiple principals can provide information to derive content permissions, but these systems lack a model of how these principals interact to make such decisions. Most systems rely primarily on one principal to make access control decisions, such as the content execution system developer (see S. Thomas, The Navigator Java Environment: Current Security Issues, at web site (URL), http://developer.netscape.com/library/documentation/javasecurity.html, which describes the Netscape 2.0 and 3.0 security model) or the user (see T. Jaeger et al., Implementation of a Discretionary Access Control Model for Scripted-based Systems, in Proceedings of the 8th IEEE Computer Security Foundations Workshop, pgs. 70-84, 1995). Most systems provide access control mechanisms, but make no commitment to how permissions are derived (see N. Borenstein, Email with a Mind of Its Own: The Safe-Tcl Language for Enabled Mail, ULPAA '94 Proceedings, pgs. 389-402, 1994 as an early example). A few systems use multiple means for deriving permissions. FlexxGuard enables users and/or system administrators to select permissions for content, but users have the ultimate decision-making power (see N. Islam et al., A Flexible Security System for Using Internet Content, in IEEE Software, pgs. 52-59, September, 1997). In Netscape's Java Capabilities API (see Netscape Communications Corp., Introduction to the Capabilities Classes, at URL html for the Netscape 4.0 security model), application developers request access rights within a limited domain specified by users and/or system administrators. However, users are not limited in the rights that they can delegate to content, and the content developer can obtain any rights within the maximal permissions by simply activating them. In a Tcl flexible content interpreter (see T. Jaeger et al., Building Systems That Flexibly Control Downloaded Executable Content, in Proceedings of the Sixth USENIX Security Symposium, pgs. 131-148, 1996.), system administrators can define how application developers may limit other content's access rights, but users may not grant rights.
RBAC models have also been used extensively to represent access control policy management, but also presently lack the flexibility to express how multiple principals can affect common access control decisions. RBAC models permit principals to assume a role, which is another principal with its own permissions. RBAC models are often used by system administrators to specify mandatory access control (MAC) policies (see R. Sandhu et al., Role-based Access Control: A Multi-Dimensional View, Proceedings of the 10th Computer Security Applications Conference). A MAC system partitions the world into two groups: (1) system administrators who specify access control policy and (2) users that are controlled by the policy. Thus, these RBAC models enable system administrators to describe the rights available to principals. The only decision a principal can make is whether to delegate all these rights to another principal. Dynamic creation of permissions to delegate to processes is not possible because of the mandatory nature of the systems. In addition, current RBAC systems that permit discretionary access control use ACLs which do not enable the creation of dynamic principals (because ACLs need to be updated). Therefore, users, content execution systems, and application developers must develop ad hoc mechanisms for flexibly and dynamically limiting the rights that are to be delegated to the content that they execute. There appears to be nothing inherently limiting about RBAC that prevents its use in dynamic derivation of rights, but current systems are not suitable for such derivation.